Skip to content

Extend api to serve standard builds path list from firmware server#242

Open
shiv-tyagi wants to merge 5 commits into
ArduPilot:mainfrom
shiv-tyagi:ap-metadata-server
Open

Extend api to serve standard builds path list from firmware server#242
shiv-tyagi wants to merge 5 commits into
ArduPilot:mainfrom
shiv-tyagi:ap-metadata-server

Conversation

@shiv-tyagi

@shiv-tyagi shiv-tyagi commented Jun 26, 2026

Copy link
Copy Markdown
Member

firmware.ardupilot.org serves standard builds for a vehicle-version-board combination. This PR extends the /vehicles api on the custom build server to serve the list of the urls for those standard builds.

This work can be independently merged without any UI change as it is an API extension. This will be used in the new custom build server frontend.

I have tested this and it works good.

image

@shiv-tyagi shiv-tyagi force-pushed the ap-metadata-server branch from ffcc1e0 to 1676bbc Compare June 26, 2026 18:29
@shiv-tyagi shiv-tyagi force-pushed the ap-metadata-server branch from 1676bbc to 6c9211f Compare June 26, 2026 18:35
@shiv-tyagi shiv-tyagi changed the title Extend api to serve standard builds path list on firmware server Extend api to serve standard builds path list from firmware server Jun 26, 2026
@shiv-tyagi shiv-tyagi requested a review from peterbarker June 26, 2026 18:36
)
return None

def get_board_standard_artifacts_from_fw_server(

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't look right. Why aren't you using the manifest file? It's there explicitly so this sort of thing is not required.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are a couple of reasons I avoided that this time.

We already have the path for firmware server builds (firmware.ardupilot.org//) for each version listed on the custom build server. We construct it in the version fetcher module.

To get the list of artifacts for a board, we just need to append the board name to it to get the exact path where that board's artifacts are stored.

We have been using this approach for quite some time. It is already used to retrieve the features.txt file. All we need to do to get the list of all versions is extend the same logic to also retrieve the list of files from there.

Using manifests.json is a much larger piece of work. We would need to download a file (over 60 MB today) asynchronously, parse it, group the entries by version and board, and then map them to the versions listed on custom.ardupilot.org (which come directly from GitHub tags).

I agree that this approach would be more correct overall, but in my opinion, extending what we already use for features.txt is the right approach for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants